Pooka SDK® is implemented by the native platform SDK through the programming languages specified by each platform. For example, the SDK is implemented by C/C++ for Windows desktop edition, C++/CX for Windows UWP edition, C/Objective-C for iOS/macOS and C++/Java for Android edition.
From the application developer's point of view, the major programming language when using Pooka SDK® is standard C/C++. The following are the basic things about programing with Pooka SDK® that developers need to remember:
Due to historical reason, there are numbers of places in Pooka SDK® API is implemented in insecure coding style. There are various reason of these insecure design in API, such as:
Unlike C#, Kotlin or certain other programming languages, standard C++ language does not support class property and requires programmers to define a pair of accessors so called "setter" and "getter" function instead.
Throughout the Pooka SDK® API, developers will find that only small numbers of setter and getter functions are provided, while many of class variables are exposed directly to developers as public class members. Although exposing class variables as public class members is considered bad practice and can generate unsafe code, Pooka SDK® does this due to historical reason. At the time when Pooka SDK® was started as a cross-platform game engine, mobile devices have extremely weak computing power and memory capacity. Minimizing the memory footprint and reduce processor overhead is one of most important thing that mobile application developers need to take care. Because of this, exposing not-so-complicated class variables instead of providing setter/getter is a practical solution, as soon as it will not easily raise up coding hazard after adequate API reference document is provided. The following picture shows class variables layoutType in class LWComponent and dimension in Object3D are exposed to developers as public class memebrs and there is an extra note reminds developers they should be treated as read-only class members.
In the next major version Pooka SDK®, setters and getters will be applied to replace those unsafe public class member.
Throughout the Pooka SDK® API, developers will find that some functions' parameter or class variables that should be defined by a C enumeration type are actually defined by int type instead, which make these functions and class variables not safe if a value not defined by the enumeration is used to call the function or assign the value of the class variable.
For example, the following API class variables and functions:
int bkgBitmapFillMode;bkgBitmapFillMode should be defined as enumeration type Content::BACKGROUND_BITMAP_FILLING_MODE int guiType;guiType should be defined as enumeration type Sprite::GUI_SPRITE_TYPE OGApplication(wchar_t * appName, int graphicsEngineType)graphicsEngineType should be defined as enumeration type Application::GRAPHICS_TYPE void drawFormattedText(int x, int y, int width, int height, wchar_t * text, unsigned int textColor, int textSize, int alignment, int transparency = 0, bool textBold = false, bool textItalic = false, bool textUnderline = false, bool useMonoFont = false)alignment should be defined as enumeration type GraphicsEngine::TEXT_ALIGNMENT In the current version Pooka SDK®, developers needs to make sure to use value defined by the corresponding enumeration when assign value or pass in function argument.
In the next major version Pooka SDK®, all those unsafe int type will be replaced by enumeration type.
Pooka SDK® is implemented in traditional C++ coding manner, it does not adopt garbage collection mechanism to recycle allocated memory, nor does it use reference counter or smart pointer to helps semi-automatic object destruction. The following code sample shows allocating and deallocating an array of string buffers by traditional C++ code:
Throughout the Pooka SDK® API reference, some API functions have to remind developers (in the API reference, highlighted by Caution token) that the returned result (string buffer, memory block, C++ instance, etc.) is dynamically allocated / created on the heap, it is the caller's responsibility to release the returned buffer or destroy the returned instance.
The following document snippet shows a function TypeUtil::valueof(int i) that reminds developers that the returned C string buffer should be released by the caller.
|
static |
Convert a integer into a wide-char C string and return it by pointer.
Caution The returned C string is dynamically created, caller needs to destroy it afterward. <----- Reminder for caller
| i | A integer |
Tip Developers can adopt any garbage collection mechanism or smart pointer in their application source code to help reduce chore in C/C++ memory management. A cross-platform solution is highly recommended for easy maintenance.
Pooka SDK® adopts Unicode character set and UTF-16 for character encoding.
wide characters. A single character takes 2 (Windows) to 4 (Unix based) bytes in storage, depends on the platform.whcar_t for character and string buffer type wcscpy(), wcscat(), wcslen(), wcsstr() and wcschr() may not have identical function name and parameter signature.When coding for a cross-platform application, take good care of the coding manner, which can affect the application performance and maintenance efficiency. As fas as the easy maintenance is concerned, developers should try to code the application in cross-platform coding manner. Although Pooka SDK® promises that API is fully cross-platform, there are other application source code written by developers may be platform dependent. Try to minimize the amount of platform dependent source code helps reduce maintenance cost. What developers can do are, for example:
_Pragma("argument") should be used (introduced in C99 standard). The following code shows an example of define a cross-platform pragma wrapper: Sometimes the platform's fragmentation make it inevitable to have fragmented code in a cross-platform application project. For example, when implemented hardware related modules, such as camera, mobile sensors, NFC and bluetooth, developers may need to write code specific to each platform.
Pooka SDK® provides technical assistance at the build-time and run-time to help application deal with platform fragmentation and maximumly reduce the maintenance cost.
Numbers of preprocessors are provided to detect target platform at the build-time. Using build-time detection can helps generate more compact and efficient application binary.
The following preprocessor helps detect the platform at the build-time (compile-time)
| Preprocessor | Meaning |
|---|---|
| _POOKA_TARGET_WINDESKTOP | Build for Windows Desktop |
| _POOKA_TARGET_WINUWP | Build for Windows UWP platform |
| _POOKA_TARGET_MACOS | Build for macOS |
| _POOKA_TARGET_IOS | Build for iOS |
| _POOKA_TARGET_ANDROID | Build for Android |
| _POOKA_TARGET_DESKTOP_OS | Build for Desktop platform (Windows and macOS) |
| Preprocessor | Meaning |
|---|---|
| _POOKA_TARGET_ARCH_X86 | Build for Intel x86 architecture |
| _POOKA_TARGET_ARCH_ARM | Build for Intel ARM architecture |
| _POOKA_TARGET_ARCH_64 | Build for 64-bit architecture |
| _POOKA_TARGET_ARCH_32 | Build for 32-bit architecture |
| Preprocessor | Meaning |
|---|---|
| _POOKA_TARGET_DEBUG | Build with debug configuration |
| _POOKA_TARGET_RELEASE | Build with release configuration |
Example 1:
Example 2:
Run-time platform detection happens only after application is running on the target device. Thus it is not efficient as build-time detection and may apply some minor overheads.
Run-time platform detection is done through numbers of classes and their properties, which are scattered but mostly in several classes including RealDevice , VirtualDevice , Application and Content .
Caution osVersionMajor and osVersionMinor are not fully implemented in current Pooka SDK®, if the info can not be retrieved, they are simply 0.
Example:
Example:
When programming a commercial application (applications published at online store for profit purpose), there are several things that developers need to pay attention further:
To most application developers, the final step of developing an application is to publish their application and sell it at platform's app store. Before an application cab be listed at platform's app store, the application must get certified by app store's certification process.
The technical details of this application certification process is beyond the scope of Pooka SDK®, besides each platform's app store may have specific certificate when assessing application.
Generally, the certification process usually has the following assessment conducted:
Developers need to spend time on each platform's application publishing guideline to prepare their application for compliance of application certification criteria. The following are some reference link for each platforms:
At application design time, there are numbers of ways to prompt developers' own branded content. For example, using customized launch image, splash image, icons, banners that can reflect brand and business image. Each platform has a detailed guideline about how to prepare those UI elements.
If an application is built by Pooka SDK® commercial edition, developers are able to set a customized splash image shown for short moment. Please note:
The customized splash image can be set through function Application::setCustomSplashImage() , refer to the API reference for more details. The following code sample shows setting a customized splash image for an application based on OGApplication class:
Read Pooka SDK® API Reference Overview to get a quick overview about Pooka SDK® API.
